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Die folgenden Artgaben sind den vom Anmelder eirtgereichten Unterlagen entnommen 

@ System und Verfahren zum Herunterladen von Anwendungsteilen auf eine Chipkarte 

@ Die vorliegende Erfindung beschreibt ein Verfahren 
zum Herunterladen von Anwendungsteilen, sogenannte 
On-Card-Anwendungsteile, von einem Server uber einen 
Client auf eine Chipkarte, wobei Server und Client uber 
ein verteiltes System, insbesondere Intranet oder Inter- 
net, miteinander kommunizieren. Die Vorteile der voriie- 
genden Erfindung iiegen darin, dass das Herunterladen 
der Anwendungsteile in zwet Stufen erfolgt: Die erste Stu- 
fe erfolgt ausschlieftlich auf dem Server und stellt sicher, 
dass nicht jedes Kommando zum Herunterladen des An- 
wendungsteils einzeln uber das Netz verschickt wird. Dies 
erfolgt mittelseines bandbreitoptimierten Protokolls, das 
die einzeinen Kommandos zum Herunterladen des An- 
wendungsteils zu etner Kommando-Sequenz zusammen- 
fasst und als ein gesamtes Datenpaket uber das Netz 
schickt. Dadurch wird die Zeit zum Herunterladen von An- 
wendungsteilen uber das Netz reduziert. Jedes Komman- 
do mnernalb der Kommando-Sequenz wird hierbei mit ei- 
1 ner digitalen Signatur versehen und gegebenenfalls ver- 
schfusselt. Damit wird sichergesteflt, dass nur authentifi- 
zierte Kommandos von der Chipkarte akzeptiert werden, 
Damit erfullt diese Erfindung sicherheitsrelevante Anfor- 
derungen beim Ubertragen von Daten uber verteilte Sy- 
steme, insbesondere uber das Internet, 
Die zweite Stufe erfolgt zwischen Client und Chipkarte 
und stellt sicher, dass die Datenpakete entpackt und ein 
zeln zur Chipkarte gesandt werden. Alle sicherhettsrele- 
vanten Schlussel und Zertifikate sind auf dem ... 


Server Schlussel 
Programm 




BUNDESDRUCKEREI 02.01 102 015/722/1 


14 


DE 199 

1 

Beschreibung 

Die vorliegende Erfindung beschreibt ein System unci 
Verfahren zum Herunterladen von Anwendungsteilen uber 
verteilte Systeme auf Chipkarten, insbesondere auf Chipkar- 
ten, die sich bereits im Einsatz befinden, 

Normalerweise werden Chipkarten mil vorbereiteten On- 
Card-Anwendungsteilen ausgeliefert. 

Diese On-Card-Anwendungsteile ennogiichen die Korn- 
munikation zwischen der Chipkarte und den Chipkartenan- 
wendungen, den sogenannten Off-Card- Anwendungen, die 
auf einem Terminal, z. B. Server- System, instaliiert sind. 
Die Chipkarte, d. h der On-Card-Anwendungsteil, kommu- 
niziert uber ein Chipkartenlesegerat mit dieser Off-Card- 
Anwendung. Moderne Chipkarten, sogenannte Multifunkti- 
ons-Chipkarten, wie z. B. Java Card oder Smart Cards fur 
Windows, haben zusatzlich die Funktionalitat, dass ON- 
Card-Anwendungsteile nachtraglich, d. h nach Auslieferung 
der Chipkarten, auf die Chipkarte gebracht werden konnen 
(siehe Fig, 1). Hierbei erfolgt das Herunterladen der On- 
Card-Anwendungsteile vom Temrinal uber das Chipkarten- 
lesegerat auf die Chipkarte, 

Z. B. VISA hat eine Open Platform Spezifikation defi- 
niert, die die Kommandos zwischen Off-Card-Anwendung 
und dem On-Card-Anwendungsteil, dem On- Card-Interface 
und den Sicherheitsstandards beschreibt. OCF (OpenCard- 
Framework) und Microsoft's PC/SC auf der anderen Seite 
adressieren die Kornmunikation zwischen Anwendung, 
Chipkartenlesegerat und Chipkarte. 

Durch den verstarkten Einsatz von verteilten Systemen 
entsteht zunehmend das Bedurfnis, On-Card-Anwendungs- 
teile uber verteilte Systenie auf die Chipkarte zu laden. Die 
Risiken soicher Verfahren iiegen auf der Hand. Das Netz un- 
terliegt unterschiedlichen Auslastungen, so dass das Herun- 
terladen je nach Auslastung vie! Zeit in Anspruch nehmen 
kann. Ein weiterer wesentlicher Aspekt ist hier die Sicher- 
heit. Alle Datenubertragen von dem Server uber den Client 
auf die Chipkarte mussen gesichert sein, Es muB ein einfa- 
ches und sicheres Authentifizierungs- und Verschlussel- 
ungsverfahren beim Herunterladen der Anwendungsteile si- 
chergestellt zum Einsatz kommen, das den unterschiedli- 
chen Auslastungen des Netzes Rechnung tragt. 

Derzeit sind der Anmelderin jedoch keine Systeme bzw. 
Verfahren bekannU die diese Einsatzmoglichkeit adressie- 
ren. 

Es ist dahcr Aufgabe der vorliegenden Erfindung, ein Sy- 
stem und Verfahren zum Herunterladen von Anwendungs- 
teilen uber verteilte Systenie auf eine Chipkarte sicherzu- 
stellen, das auf einfache Weise unter Berlicksichtigung der 
erforderiichen sicherheitsrelevanten Uberprufungen erfolgt. 

Diese Aufgabe wird durch die Merkmale der Anspriiche 
1, 17 t 18 und 20 gelost Vorteiihafte Ausfuhrungsformen der 
vorliegenden Erfindung sind in den Unteranspriichen nie- 
dergelegt. 

Die Vorteile der vorliegenden Erfindung liegen darin, 
dass das Herunterladen der Anwendungsteile in zwei Stufen 
erfolgt: 

Die erste Stufe erfolgt ausschlieBlich auf dem Server und 
stellt sicher, dass nicht jedes Kornmando zum Herunterladen 
des Anwendungsteils einzeln uber das Netz verschickt wird. 
Dies erfolgt mittels eines opfimierten Protokolls, das die 
einzelnen Kommandos zum Herunterladen des Anwen- 
dungsteils zu einer Kommando-Sequenz zusammenfasst 
und als ein Datenpaket uber das Netz schickt. Dadurch wird 
die Zeit zum Herunterladen von Anwendungsteilen liber das 
Netz reduziert. Jedes Kornmando innerhalb der Kommando- 
Sequenz wird mit einer digitale Signatur versehen und gege- 
benfalls verschlusselt, Darnit wird sichergestellt, dass nur 
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authentifizierte Kommandos von der Chipkarte akzeptiert 
werden. 

Darnit erfullt diese Erfindung sicherheitsrelevante Anfor- 
derungen beim Ubertragen von Daren uber verteilte Sy- 
5 steme, insbesondere das Internet. 

Die zweite Stufe erfolgt zwischen Client und Chipkarte 
und steiit sicher, dass die Datenpakete entpackt und einzeln 
zur Chipkarte gesandt werden. 

Alle sicherheitsrelevanten Schliissel und Zertifikate wer- 
io den auf dem sicheren Server abgelegt. Die Kornmunikation 
zwischen Client und Server erfolgt vorzugsweise liber SSL 
(Secure Sockets Layer) als Ubertragungsprotokoll. Der 
Missbrauch des erfinderischen Systerns/Verfahrens wird 
hierdurch wesentfich erschwert. 
is Die vorliegende Erfindung wird anhand bevorzugter Aus- 
flihrungsbeispiele anhand Figuren naher beschrieben, wobei 
Fig. 1 den Stand der Technik der Kornmunikation zwi- 
schen Off-Card-Anwendung und On-Card-Anwendungsteil 
zeigt, 

20 Fig. 2 eine vcrtcile Kommunikationsarchitektur zeigt, die 
der vorliegenden Erfindung zugrunde liegt, 

Fig. 3 die erfinderischen Schritte beim Herunterladen von 
On-Card-Anwendungsteilen von einem Server liber ein 
Netz auf eine Chipkarte zeigt, 
25 Fig. 4 die erfinderische Architektur nach Fig. 3 in einer 
Java-Implementierung zeigt, 

Fig. 5 die erfinderischen Schritte beim Herunterladen von 
On-Card-Anwendungsteilen von einem Server uber Netz 
auf eine Chipkarte in einer Java-Implementierung zeigt. 
30 Fig. 1 zeigt den Stand der Technik beim Herunterladen 
von On-Card-Anwendungsteilen von einem Terminal auf 
die Chipkarte und die Kornmunikation zwischen On-Card- 
Anwendungsteil und Off-Card-Anwendung, En Stand der 
Technik bestehen Chipkartenkartenanwendungen aus einer 
35 Off-Card-Anwendung, die auf einem Terminal abgespei- 
chert ist, und einem On-Card-Anwendungsteil, der auf der 
Chipkarte im nichtfliichtigen Speicher abgelegt ist (siehe 
Fig. 1). Das Terminal besteht aus einem Datenverarbei- 
tungsgerat mit einem Chipkartenleser und der entsprechen- 
40 den Treibersoftware fiir den Chipkartenleser. Der On-Card 
Anwendungsteil kommuniziert mit der Off-Card-Anwen- 
dung liber mehrere Schichtem Schicht 1 definiert das physi- 
kalische Transportprotokoll. Schicht 2 setzt auf dieses Pro- 
tokoll ein logisches, byte-orientiertes Protokoll. Schicht 3 
45 bildet hohere Programrniersprache auf Schicht 2 ab, Ein 
Beispiel fur die Schicht 1 ist das Protokoll T = 0, T = 1 (ISO/ 
IEC7816-3), Schicht 2 APDU ProtokoU(ISO/7816-4), 
Schicht 3 OCF(Open Card Framework) oder PCSC(). 
Normalerweise wird der On-Card-Anwendungsteil liber 
50 eine Ladeapplikation, die im Terminal lauft, auf die Chip- 
karte ubertragen. Hierbei werden geeignete Kommandos der 
Chipkarte verwendet (z, B. bei File-orientiertenchipkarten 
"CREATE- und UPDATE Kommandos"). Derzeit gibt es 
noch keine bekannte Losung zur Ubertragung von On-Card- 
55 Anwendungsteilen liber verteilte Systeme auf die Chipkarte. 
Fig. 2 zeigt die erfinderische Architektur der vorliegen- 
den Erfindung. 

Die erfinderische Architektur basiert auf einer Client/Ser- 
ver-Architektur. Der Client kommuniziert mit dem Server 
60 Uber ein Netzwerk, z. B. dem Internet oder Intranet. Der 
Client ist mit einem Chipkartenleser verbunden und nur der 
Server hat Zugriff auf die geheimen Schliissel, die zum Her- 
unterladen von On-Card- Anwendungsteilen auf die Chip- 
karte erforderlich sind. Die Schliissel konnen entweder auf 
65 dem Server seibst oder auf einem weiteren System abgelegt 
sein, auf das der Server Zugriff hat. Die Chipkarte ist gegen 
unberechtigtes Herunterladen von On-Card- Anwendungs- 
teilen derart gesichert, dass sie Kommandos nur dann akzep- 
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tiert, wenn sie mit den richtigen Schliisseln signiert und/oder 
verschlusselt sind. Auf dem Client niu8 zur Lauf2eit ein 
Programm existieren, das sowohl mit der Chipkarte als auch 
dem Server kommuniziert und das ein Protokoll implemen- 
tiert, das von der jeweiiigen Chipkarte abhangt. 5 

In diesem Protokoli 1st festgelegU wann weiche Nachrich- 
ten mit der Chipkarte und dem Server ausgetauscht werden 
mussen. Auf dem Server rnuS zur Laufzeit ein Programm 
existieren, das mit dem Client kommuniziert und bei Bedarf 
die dern Server zuganglichen Schlussel verwendet, und das to 
ein Protokoll implementiert, das festlegt, wann weiche 
Nachrichten mit dem Client ausgetauscht werden mussen 
und wann weiche Schlussel verwendet werden mussen. Bei 
der Chipkarte handelt es sich urn gangige Chipkarten (z, B. 
Java Card oder File orientierte Chipkarten), die fur die vor- is 
liegende Erflndung nicht angepaBt werden mussen. 

Fig. 3 zeigt die erfinderischen Schritte beirn Herunterla- 
den von On-Card-Anwendungsteilen von einem Server iiber 
ein Netz auf eine Chipkarte. 

Der Client stellt eine Kommunikation zur Chipkarte und 20 
zum Server her 

Der Client stellt einen Request an den Server, dass ein 
On-Card-Anwendungsteil (Anwendungsteil A) auf die 
Chipkarte gebracht werden solL Client und Server kommu- 
nizieren vorzugsweise iiber TCP/IP oder HTTP 25 

Der Server sendet eine Response an den Client, rnit der 
Aufforderung, die Chipkartenidentifikationsdaten und gege- 
benenfalls eine Zufallszahl zur Authentifikation zu senden. 
Chipkartenidentifikationsdaten beinhalten zumindest Daten 
uber den Chipkartentyp und die Chipkartennummer. 30 

Der Client empfangt die Response vom Server und sendet 
geeignete Kommando-APPUs an die Chipkarte, urn die 
Chipkartenidentifikationsdaten und gegebenenfalls eine Zu- 
fallszahl zu erhalten. Die Chipkartenidentifikationsdaten 
sind im nichtftiichtigen der Chipkarte abgelegt und konnen 35 
durch geeignete Koinmandos ausgelesen werden. Die Chip- 
karte empfangt die Kommandos und gibt die Chipkarteni- 
dentifikationsdaten und gegeben falls die Zufallszahl an den 
Client zuriick. Der Client sendet diese Daten in einem Re- 
quest an den Server. 40 

Der Server empfangt den Request und wertet die Chip- 
kartenidentifikationsdaten aus, um herauszufinden, weiche 
Schlussel verwendet werden mussen bzw. um die erforderii- 
chen Schlussel aus Master-Schlusseln abzuleiten, um den 
Anwendungsteil A herunterladen zu konnen. Die Schlussel 45 
werden verwendet, um eine Kommando-Sequenz fur das 
Herunterladen der Anwendung A von dem Server auf die 
Chipkarte vorzubereiten, Diese Kommando-Sequenz be- 
wirkt auf der Chipkarte die Erzeugung der Anwendung A. 
Die Kommando-Sequenz ist eine vordefinierte Sequenz, die so 
nichtfliichtigen Speicherbereich des Servers fur eine be- 
stimmte Anwendung abgelegt ist. Eine weitere Ausfuh- 
rungsform ist, dass die Kommando-Sequenz ganz oder teil- 
weise mit Hilfe eines Programms auf dem Server erzeugt 
wird. Dies wird vorzugsweise dann angewendet werden, 55 
wenn mit Hilfe der Kommando-Sequenz auch kartenindivi- 
duelle Daten mit in den On-Card-Anwendungsteil integriert 
werden sollen. Vorzugsweise wird jedes Kommando inner- 
halb der Sequenz mit Hilfe des Schlussels (SessionKeys) si- 
gniert und gegenfalls verschlusselt. Dies kann zum Beispiel 60 
dadurch erfolgen, dass das erste Kommando innerhaib der 
Sequenz mil Hilfe der Zufallszahl und des richtigen Schliis- 
sels mit einem MAC (message authentification code) verse- 
hen wird und alle nachfolgenden Kommandos mit Hilfe des 
MACs des vorangehenden Kommandos und des richtigen 65 
Schlussels mit einem MAC versehen werden. Die Sequenz 
mit den signierten und gegebenenfalls verschlitsselten Kom- 
mandos wird zum Client gesendet. 


Der Client empfangt die Response mit der Kommando- 
Sequenz und sendet die Kommandos nacheinander zur 
Chipkarte. Die Chipkarte uberpruft die Signatur und fuhrt 
die Kommandos nur bei Richtigkeit aus. 

Fig. 4 zeigt die erfinderische Architektur nach Fig, 3 in 
einer JavaTmplementierung. 

Auf dem Client lauft ein Web-Browser mit dessen Hilfe 
der Benutzer zur Web-Seite des Servers navigieren kann. 
Auf der Web-Seite des Servers befindet sich das Applet, das 
das in Fig. 3 beschriebene Client-Programm iniplementierL 
Dieses Applet wird beim Anzeigen des Web-Seite vom Ser- 
ver in den Browser heruntergeladen. Das Applet baut eine 
Kommunikationsverbindung zu einem Servlet auf dem Ser- 
ver auf Das Servlet besitzi die Funktionalitat des Server- 
Programms. 

Der Verfahrensablauf zum Herunterladen des On-Card- 
Anwendungsteils entspricht dem in Fig. 3. 

Fig. 5 zeigt die erfinderischen Schritte zum Herunterla- 
den von On-Card-Anwendungsteilen von einem Server uber 
Netz auf eine Chipkarte in einer Java-Implementierung. 

Hierbei soil davon ausgegangen werden, dass eine Broke- 
rage- Anwendung, die auf einem Server abgelegt ist, auf die 
Chipkarte geladen werden soil. Auch Schlussel zur Authen- 
tifizierung sind auf, dem Server abgelegt. 

Der Client stellt eine Kommunikation zur Chipkarte und 
zum Server her. Die Kommunikation zur Chipkarte wurde 
mittels OCF (OpenCardFramework) realisiert. 

Der Client stellt einen Request an den Server, dass die 
Brokerage-Anwendung (On-Card-Anwendungsteil) auf die 
Chipkarte gebracht werden soli. Client und Server kommu- 
nizieren vorzugsweise uber TCP/IP oder HTTP 

Der Server sendet eine Response an den Client, mit der 
Aufforderung, die Chipkartenidentifikationsdaten (hoieKar- 
tenlnfo) zu senden, 

Der Client empfangt die Response vom Server und sendet 
geeignete Kommando-APPUs an die Chipkarte, um die 
Chipkartenidentifikationsdaten zu erhalten. Die Chipkarte- 
nidentifikationsdaten sind im nichtfluchtigen der Chipkarte 
abgelegt und konnen durch geeignete Kommandos ausgele- 
sen werden. Die Chipkarte empfangt die Kommandos und 
gibt die Chipkartenidentifikationsdaten an den Client zu- 
riick. Der Client sendet diese Daten in einem Request an den 
Server. 

Der Server empfangt den Request und wertet die Chip- 
kartenidentifikationsdaten aus, um herauszufinden, um wel- 
chen Kartentyp cs sich handelt. Abhangig von diesem Kar- 
tentyp wird eine Methode zur Authentifizierung ausgewahlt. 
In der vorliegenden Implementierung ist der Kartentyp eine 
VISA Open Platform Karte mit symmetrischen Schliisseln. 
Der erste Schritt der Authentifizierung besteht darin, dass 
der Server eine Zufallszahl generiert und einen Schliissef 
nummer auswahlt und diese Infonnationen in einem Kom- 
mando verpackt und an den Client sendet. Der Client extra- 
hiert das OCF Kommando und sendet dieses an das OCF In- 
terface auf dem Client Rechner. Das OCF Interface wandelt 
das OCF Kommando in eine oder mehrere APDUs um und 
sendet diese an die Chipkarte. Die Chipkarte empfangt die 
APDUs, stellt fest, dass es sich um eine Authentifizierung- 
Komrnando handelt, generiert eine Zufallszahl, und bildet 
aus beiden Zufallszahlen und dem mitgeteilten Schlussel ei- 
nen Session Key (Schlussel) und sendet die Zufallszahlen 
damit verschlusselt zuriick. 

Der Client gibt die Antwort der Karte an den Server. Der 
Server generiert aus den beiden Zufallszahlen und der 
Schiusselnummer ebenfalls einen SessionKey. Mit Hilfe 
dieses SessionKeys uberpruft er die verschlusselten Zufalls- 
zahlen. Bei erfolgreicher Uberpriifung wird die Karte als au- 
thentifiziert angesehen. 
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Der Server sendet ein zweites Authentifizierungskom- 
mando an den Client, um sich nach dem gleichen Verfahren 
- wie vorher beschrieben - zu authentifizieren. Bei erfolg- 
reicher Uberprufung wird der Server als authentifiziert an- 
gesehen, 5 

Die Brokerage- An wendung wird auf dem Server mittels 
der SessionKeys signiert und gegebenenfalls verschiusseit, 
um die Brokeranwendung herunterladen zu konnen. Diese 
KommandoSequenz bewirkt auf der Chipkarte die Erzeu- 
gung der Brokerage- An wendung A. Die Komrnando-Se- 10 
quenz ist eine vordefinierte Sequenz, die nichtfluchtigen 
Speicherbereich des Servers abgelegt ist. Eine weitere Aus- 
fuhrungsform ist, dass die Kommando-Sequenz ganz oder 
teilweise mit Hilfe eines Programms auf dem Server erzeugt 
wird. Dies wird vorzugsweise dann angewendet werden, 15 
wenn mit Hilfe der Kommando-Sequenz auch kartenindivi- 
duelle Daten mit in den On-Card-Anwendungsteil imegriert 
werden sollen. 

Vorzugsweise wird jedes Kommando innerbalb der Se~ 
qucnz mit Hilfe des Schliissels signiert und gegebenenfalls 20 
verschiusseit. Dies kann zum Beispiel dadurcb erfolgen, 
dass das erste Kommando innerhalb der Sequenz mit Hilfe 
der Zufallszahl und des richtigen Schliissels mit einem 
MAC (message authentification code) versehen wird und 
alle nachfoigenden Kommandos mit Hilfe des MACs des 25 
vorangehenden Kommandos und des richtigen Schliissels 
mit einem MAC versehen werden. Die Sequenz mit den si- 
gniert.en und gegebenenfalls verschliisselten Kommandos 
wird zum Client gesendet. 

Der Client empfangt die Response mit der Kommando- 30 
Sequenz und sendet die Kommandos nacheinander zur 
Chipkarte, Die Chipkarte uberpruft die Signatur und tuhrt 
die Kommandos nur bei Richtigkeit aus. 

Die erlauterten Verfahrensschritte konnen auch zur Perso- 
nalisierung der neuen An wendung/Brokerage- An wendung 35 
dienen. 

Patentanspriiche 

1. Verfahren zum Herunterladen von Anwendungstei- 40 
len von einem Server liber ein Client auf eine Chip- 
karte, wobei der Server und der Client uber ein verteil- 
tes System miteinander verbunden sind, gekennzeich- 
net dureh folgende Schritte: 

a) Bereitstellen eines geheimen Schliissels oder 45 
SessionKeys durch den Server 

b) Laden einer Kommando-Sequenz von Befeh- 
len zum Herunterladen des Anwendungsteils auf 
die Chipkarte 

c) Generieren einer digitalen Signatur mit dem 50 
geheimen Schliissel oder SessionKey liber jedes 
Kommando innerhalb der Kommando-Sequenz 

d) Senden der signierten Kommando-Sequenz als 
Datenpaket an den Client 

e) Entpacken des Datenpakets und Senden der 55 
einzelnen Kommandos der Sequenz nacheinander 
zur Chipkarte 

0 Uberpriifen der digitalen Signatur der einzel- 
nen Kommandos und Ausfuhrung der Komman- 
dos bei Richtigkeit der digitalen Signatur, 60 

2. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, dass das Authentihzierungsverfahrerv zur Generie- 
rung des SessionKeys durch folgende Schritte ausge- 
wahlt wird: 

a) Senden einer Anfrage vom Server uber den 65 
Client an die Chipkarte zur Ubermittlung der auf 
der Chipkarte abgelegten Chipkartenidentifikati- 
onsdaten 
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b) Ausiesen der Chipkartenidentifikationsdaten 
aus dem nichtfluchtigen Speicher der Chipkarte 
und Ubermittlung der Chipkartenidentifikations- 
daten iiber den Client zum Server 

c) Ermitteln aus den Chipkartenidentifikationsda- 
ten ein A uthenti ft zierung verfahren mit dessen 
Hilfe ein zwischen Server und Chipkarte verein- 
barter SessionKey generiert werden kann. 

3. Verfahren nach Anspruch 2, dadurch gekennzeich- 
net, dass der SessionKey durch ein Authenufizierungs- 
verfahren mit folgenden Schritten bestirnrnt wird; 

a) Generieren einer Zufallszahl und Auswahlen 
eines geheimen Schliissels durch den Server 

b) Senden der Zufallszahl nach Schritt a) liber 
den Client zur Chipkarte 

c) Generieren einer Zufallszahl durch die Chip- 
karte 

d) Bilden aus beiden Zufallszahlen und mitgeteit- 
ten Schliissel einen SessionKey 

c) Senden der verschliisselten Zufallszahlen und 
der von der Chipkarte generierten Zufallszahl zum 
Server 

f) Generieren eines SessionKeys durch den Ser- 
ver und Uberpriifen der verschliisselten Zufalls- 
zahlen mit Hilfe des SessionKeys. 

4. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, dass das verteilte System das Intranet oder Internet 
ist. 

5. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, dass die Kommunikation zwischen Server und 
Client uber SSL (Secure Sockets Layer) als Ubertra- 
gungsprotokoll erfoigt. 

6. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, dass auf dem Server zur Laufzeit ein Programm 
existiert, das mit dem Client kommuniziert und bei Be- 
darf die dem Server zuganglichen Schliissel verwendet 
und das Protokoll festlegt, wann welche Nachrichten 
mit dem Client ausgetauscht und wann welche Schliis- 
sel verwendet werden miissen, und dass auf dem Client 
zur Laufzeit ein Programm existiert, das sowohl mit 
der Chipkarte als auch dem Server kommuniziert und 
das Protokoll implementiert, das festlegt, wann welche 
Nachrichten mit der Chipkarte und dem Server ausge- 
tauscht werden miissen. 

7. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, dass die Chipkartenidentifikationsdaten zumindest 
aus einer Chipkartenserienurnmer und einem Chipkar- 
tentyp bestehen. 

8. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, dass die digitale Signatur uber einen symmetri- 
schen Kryptoalgorithrnus mit Hilfe des SessionKeys, 
der zwischen Client und Server vereinbart wird, oder 
uber einen asymmetrischen Kryptoalgorithrnus mit 
Hilfe eines privaten Schliissels erfoigt, der auf der 
Chipkarte liegt, wobei der Server im Besitz des offent- 
lichen Schliissels ist. 

9. Verfahren nach Anspruch 8, dadurch gekennzeich- 
net, dass der symmetrische Kryptoalgorithrnus DES 
oder Trible-DES und der asymmetrische Kryptoalgo- 
rithrnus RSA, DSA oder ein Eliptic-Curve-Algorith- 
mus. 

10. Verfahren nach Anspruch 3, dadurch gekennzeich- 
net, dass rnit Hilfe der Chipkartenidentifikationsdaten 
und des MasterKeys der geheirne Schliissel abgeleitet 
wird, 

11. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, dass die Kommando-Sequenz zumindest aus ei- 
nem In stall- Befehl, ein oder rnehreren Load- Be feh len 
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und einem ahschlieSenden Instali-Befehi besteht und in 
einer APDU-Struktur niedergelegt ist. 

12. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, dass mittels des SessionKeys jedes Kommando in- 
nerhalb der KommandoSequenz verschliisselt wird, 5 

13. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, dass die KommandoSequenz eine vordefinierte 
Sequenz fur eine bestimmte Anwendung ist, die auf 
dem nichtfliichugen Speicher des Servers gespeichert 

ist und zur Laufzeit in den fliichtigen Speicher des Ser- 10 
vers geladen werdem 

14. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, dass die KommandoSequenz durch das Server- 
Programm nach Anspruch 6 zur Laufzeit generiert 
wird. 1 5 

15. Verfahren nach Anspruch 14, dadurch gekenn- 
zeichnet, dass in die KommandoSequenz kartenindivi- 
duelle Daten eingebunden werden. 

16. Verfahren nach Anspruch 13, dadurch gekenn- 
zeichnet, dass das erste Kommando innerhalb der Se- 20 
quenz mil Hilfe der Zufallszahl und des geheimen 
Schliissels mit einem MAC(message authentification 
code) versehen wird und alle nachfolgenden Komman- 
dos mit Hilfe des MACs des vorangehenden Komman- 
dos und des Schliissels mit einem MAC versehen wer- 25 
den. 

17. Vorrichtung, zumindest enthaltend folgende Kom- 
ponenten: 

a) Client zumindest enthaltend; 

aa) einen Browser 30 
bb) ein Computerprogrammprodukt zur 
Ausfuhrung des Verfahrens^chritts e) nach 
Anspruch 1 

cc) ein Lesegerat fur die Chipkarte 

b) Server enthaltend zumindest: 35 

aa) ein Computerprogrammprodukt zur 
Ausfuhrung der Verfahrensschritte a) bis d) 
nach Anspruch 1 

bb) einen nichtfliichtigen Speicher zur Spei- 
cherung der geheimen Schlussel bzw. des 40 
MasterSchllissels 

c) eine Kommunikationsverbindung zwischen 
Client und Server. 

18. Client zumindest enthaltend: 

a) ein Browser 45 

b) ein Computerprogrammprodukt zur Ausfuh- 
rung des Verfahrensschritts e) nach Anspruch 1. 

19. Client nach Anspruch 17 weiter enthaltend; 

c) ein Chipkartenlesegerat 

d) eine Chipkarte mit einem nichtfluchtigen Spei- 50 
cher zumindest enthaltend folgende Daten: 

aa) eine Kartennummer 

bb) ein Kartentyp 

cc) einen geheimen Schlussel, 

20. Compute rprogrammprodukt, das im intemen Spei- 55 
cher eines digitalen Rechners gespeichert ist, enthal- 
tend Teile von Softwarecode zur Ausfuhrung des Ver- 
fahrens nach Anspruch 1 bis 16, wenn das Produkt auf 
derrt Rechner ausgefuhrt wird. 
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